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(57) Abstract: An e-mail system includes an address book (108) that registers all e-mail correspondents wishing to send messages 
(202) to a particular user recipient. All e-mail directed to the user from outside is blocked unless the sender is registered in the address 
book and has a valid token (200). A limited number of such tokens are issued to each correspondent, and only after the sender has 
satisfactorily disclosed their identity. Such tokens limit the amount of access to a recipient. If the recipient later decides that any 
such sender is, in fact, a spammer, then any further e-mail from that sender can be blocked. 
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E-MAIL SPAM ELIMINATION METHOD AND SYSTEM 
5 Background Of The Invention 

Technical Field 

10 The present invention relates to electronic mail (e-mail), and more specifically to 
methods and systems for controlling the delivery of unwanted e-mail messages (spam). 

Description Of The Prior Art 

1 5 Unwanted e-mail, or spam, is becoming a great nuisance. Spammers are becoming 
more adept at being annoying and getting around ordinary filters. One way they do this 
is to hide their real e-mail sending address and plug in some phony one. They then use 
a new return e-mail address for every new piece of spam. Although every spammer is 
ultimately trying to sell something, they all seem to prevent a simple e-mail reply. 

20 Instead, you must go to a website or call a phone number where you must listen to a 
long recorded message and leave a voice-mail message. 

More advanced e-mail filters are able to recognize keywords and phrases in the subject 
and message body, and then use the occurrence of these in a new message to block 
25 out the whole message. For example, "get rich quick" or "buy now" appearing in the 
subject line could signal an unwanted message. Eudora is an example of an e-mail 
application that includes a highly developed user-programmable filter. 

But such filters can also block messages from desirable correspondents, so great care 
30 must be used in the selection of the keywords and phrases. A monitor also needs to 
be setup so the blocked messages can be reviewed to make sure acceptable 
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messages are not being filtered out. Systems like that described by Lucent 
Technologies (Murray Hill, NJ) in European Patent Application EP-0-899-918-A2, 
"System and method for providing anonymous remailing and filtering of electronic mail", 
• published 03.03.1999, strip away the real source's address in e-mails and render the 
5 messages sent anonymous. Prior art filters can do little to stop such trickery. 

The general problem with conventional spam eliminators is they must know something 
about the spammer and their messages in order to block them. Spammers use this 
weakness to their advantage by constantly finding subjects, messages, and retum e- 
1 0 mail addresses that seen inoffensive. 



European Patent Application EP-0-813-162-A2, published 17.12.1997, titled "Method 
and apparatus for identifying and discarding junk electronic mail", depends on a group of 
trusted users to collectively determine what is junk e-mail. Once a piece is labeled as 
fink e-mail, unviewed copies in the e-mail systems of the other trusted users are 
immediately disposed of. Single users thus get far less junk e-mail, especially in large 
organizations. However, someone must get stung first before the e-mail is blocked 
entirely by the system. A very similar approach is repeated in United States Patent 
6,052,709, titled "Apparatus and method for controlling delivery of unsolicited electronic 
mail", which was issued April 18, 2000, to Sunil Paul. 

Two filters are used in the method and system described by William B. McCormick, et 
al., in United States Patent 6,023,723, issued Feb. 8, 2000. A first filter is supplied with 
e-mail sender addresses the user does not want to receive messages from. A second 
25 filter is loaded with those e-mail sender addresses that the user does want to receive. 
Messages caught by the first filter are simply dumped. Messages recognized by the 
second filter are passed through for delivery. Messages ftx)m addresses not brought to 
the attention of either filter are fonvarded to a "waiting room" for the user to took at later. 
Any messages in this waiting room that are later rejected by a user's review are gleaned 
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for information tliat is fopA/arded to a central system. A master-list update is then 
conripiled for tiie first filters of all users/subscribers. 



5 Summary Of The Invention 

An e-mail system includes an address book that registers all e-mail correspondents 
wishing to send messages to a particular user recipient. All e-mail directed to the user 
from outside is blocked unless the sender is registered in the address book and has a 
10 valid token. A limited number of such tokens are issued to each correspondent, and 
only after the sender has satisfactorily disclosed their identity. Such tokens limit the 
amount of access to a recipient. If the recipient later decides that any such sender is, h 
fact, a spammer, then any further e-mail from that sender can be blocked. 

15 

Brief Description Of The Drawings 

Fig. 1 1s a top-level flowchart of an e-mail server embodiment of the present invention; 
FiQ. 2 is a flowchart of the Sendmail subroutine of Fig. 1 ; 
20 Fig. 3 is a flowchart of the Procmail subroutine of Fig. 1 ; 

Fig. 4 is a flowchart of the PERL script "asptestpl" subroutine of Fig. 1; 

Fig. 5 is a flowchart of the PERL script "dumpit.pl" subroutine of Fig. 1 ; 

Fig. 6 is a flowchart of the PERL script "getaddr.pl" subroutine of Fig. 1 ; and 

Rg. 7 is a flowchart for creating user accounts In an embodiment of the present invention. 

25 

Detailed Description Of The Invention 



Fig. 1 represents an e-mail sender embodiment of the present invention, and is refenBd 
to herein by the general reference numeral 100. A new e-mail message 102 enters a 
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sendmail subroutine 1 04 which inspects the "from" address header included in the e- 
mail. The whole e-mail is either then forwarded to a deliver-message subroutine 106 or 
a procmail subroutine 108, depending on whether the sender is an acceptable and 
known correspondent who has been preregistered in the system. Procmail 108 calls on 
an asptest.pl subroutine 110, adumpit.pl subroutine 112, and a getaddr.pl subroutine 
114, to process the incoming e-mails for acceptability to the user. PERL-script 
Implementations are preferred, as indicated by the ".pi" extensions mentioned herein for 
the subroutine files. Some of the processed e-mails can be returned by procmail 1 08 
to sendmail 104 for ultimate delivery to the user. 

Fig. 2 details a sendmail subroutine 200 which is similar to the sendmail subroutine 1 04 
(Fig. 1). A new e-mail message 202 Is passed on to an address domain parser 204. 
The "from" address header in the message received is checked to see if the domain 
matches a preregistered domain, e.g., one that is known to the user or the e-mail 
system. If the domain does match a preregistered domain, and has a suffix of 
".procmail", a step 206 strips the address of the ".procmail" suffix. A step 208 parses 
the e-mail recipient header e.g., with getaddr.pl subroutine 114, and delivers the e-mail 
In a step 210. If the message Is from an unknown source, e.g., the domain does not 
match any preregistered domain, the "from" address header is rewritten in a step 212 as 
"domain.procmail" and the whole message is piped through procmail by a step 214. 

Fig. 3 details a procmail subroutine 300 which is similar to the procmail subroutine 1 08 
(Fig. 1). A new e-mail message 302 is passed on to a step 304 which generates a 
proper "from" address header. A step 306 checks for an "x-loop:" header entry. If one 
is not found, a step 308 makes a copy of the message and sends it to the asptest.pl 
subroutine 110. If the test in the asptest.pl subroutine returned a "no", then the 
message Is dumped In a step 310 that trashes it with dumpit.pl subroutine 1 12. But if 
the test in the asptest.pl subroutine returned a "yes", then the message is fonwarded to 
a step 312. Such parses the recipient field from the e-mail header by calling the 
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getaddr.pl subroutine 114. A step 314 then bounces the message on to the 
recipient/user. 



Fig. 4 details an asptest.pl subroutine 400 which Is sinriilar to the asptest.pl subroutine 
5 110 (Fig. 1). A new e-mail message 402 Is passed on to a step 404 which parses the 
sender and recipient info from the e-mail message header. Such parsed-out address 
information is then used by a step 406 to generate a hypertext transfer protocol (HTTP) 
message. This is then sent to an active server pages (ASP) application running on a 
webserver, e.g., WINDOWS-NT with IIS. Such http-message can be communicated 
1 0 over any network, especially over the Intemet via TCP/IP. A centralized system would 
then be possible that could be used to share prereglstration Infonmation and any 
information generated about spammers. 

The websen/er's ASP typically responds with one of four commands amounting to, (a) 
15 "deliver the e-mail", (b) "deliver the e-mail with fomi attached", (c) "reply and attach 
error", or (d) "delete the e-mail". If the answer is anything but "deliver e-mail", an error 
message to the user Is generated. A step 408 parses the ASP response. A step 41 0 
generates an exitcode from the ASP response, and a step 412 returns the error 
message to procmail subroutine 108 and exits, Procmail uses the exitcode and error 
20 message to decide whether to "deliver the e-mail" or to trash it by sending it to the 
dumplt.pl subroutine 1 12. The "deliver the e-mail" choice uses the getaddr.pl subroutine 
1 14 to parse out the recipient. The e-mail is then bounced to the recipient in step 314. 



Fig. 5 details a dumpit.pl subroutine 500 which is similar to the dumpit.pl subroutine 1 1 2 
25 (Fig. 1). A new e-mail message 502 and an error message 504 are passed on to a 
step 506 which is to dump the message, reply to it, or to attach a fomri. If the decision Is 
to "delete the e-mail", a null step 508 simply exits without doing anything. If the decision 
is to "reply and attach en-or", a reply header is generated in a step 510. A step 512 
appends the en-or message to the e-mail, and a step 514 sends the new e-mail. But if 
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the decision in step 506 is to "deliver tlie e-mail with form attached", a step 516 uses the 
getaddr.pl subroutine to parse the recipient from the e-mail header. A step 518 
appends a hypertext markup language (HTML) fomi, and sends the e-mail to the 
recipient in a step 520. 

Fig. 6 details a getaddr.pl subroutine 600 which is similar to the getaddr.pl subroutine 
1 12 (Fig. 1). A new e-mail message 602 has its header parsed in a step 604 for its 
recipient infomiation. A step 606 returns to the calling program with the recipient 
address. 

Fig. 7 represents a method for creating new user accounts with the systems described h 
Figs. 1-6, and Is refen-ed to herein by the general reference numeral 700. The method 
700 is preferably included in a business model embodiment of the present invention. 
A profitable business can be constructed with an implementation from Figs. 1-7 that 
operates over the Intemet and uses HTTP, HTML, and simple mail transfer protocol 
(SMTP) documents with both webpage servers and mail servers. The users are 
required, at least initially to enroll and load preferences, to have an Intemet client and 
browser. Such Intemet client is used in step 406 to ask the ASP what to do with 
particular messages received. The SMTP mail sen/er delivers the basic e-mail 
messages, and the webservers use the Intemet to communicate filter infomiatfon 
between usere and a centralized database. Such database and webserver is operated 
at a profit by charging users a subscription fee or per-use fee. 

The new user account creation method 700 begins with a fill-in fomi 702 that can be 
Implemented with JavaScript and HTML-code generated by the ASP in the 
webserver. An information 704 includes user data that Is needed to enroll a user h a 
system like that described In Figs. 1-6. A step 706 validates the information submitted, 
e.g., by rule-based checking. It confirms receipt by the provider to the newly enrolled 
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user. A step 708 downloads the verified information to the database for real-time use 
over the Internet. 



In general, embodiments of the present invention defaults to blocking mail from aO 
5 unknown sources. Any e-mail from known and acceptable sources are preferably 
viewable in a user directory free of unsolicited messages. Senders wishing to send 
messages to recipient-users, and who are unknown, must register wrth a central control 
system. For example, an Internet websen/er is provided as a central control and 
registry. Those registering must identify themselves sufficient to satisfy tiie system 
10 operators and users. A limited number of tokens are then electronically credited to such 
previously unknown senders. The limits on the number of tokens allotted prevents 
mass mailings. Recipient-users who do have the sender listed as a known and 
acceptable source can authorize mail delivery without requiring any tokens. 

15 Messages that are sent with tokens and accepted by their intended recipients wiH 
preferably automatically generate more tokens for use by the corresponding sender. 
This is equivalent to rewards for good behavior, or the way credit is established by 
establishing a record of responsible conduct. It also limits the volume of mail that can be 
sent by one sender, and thus makes the sending of junk e-mail uneconomical. Any e- 

20 mail received by using tokens as passports is sent to a directory in which the users know 
the messages inside may be unsolicited and require validation. 



A system of validation levels can be applied to authorized users. A "caller-ID" level 
confimns valid "from" e-mail addresses. A second level check if the sender's physical 
25 address is acceptable. A third level check If the sender's phone number is acceptable. 
A fourth level check if the sender has a valid certificate. Corporate senders can also be 
classified as non-profit or having paid a fee. Such fees can be collected by the system 
operator, or credited to individual recipients. 
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Such validation levels, fee payments, non-profit senders, and the implementation of 
tokens can be included in the constructbn of the asptest.pl subroutine 110 and 400. A 
con-esponding application program is included m the ASP program on the responsible 
webserver. 

5 

Although the invention is described herein with reference to the preferred embodiment, 
one skilled in the art will readily appreciate that other applications may be substituted for 
those set forth herein without departing from the spirit and scope of the present 
invention. Accordingly, the invention should only be limited by the claims included 
10 below. 
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Claims 



1 . A method for stopping unwanted messages from being accepted in an e-mail 
5 delivery system, comprising: 

receiving an e-mail message from a sender via an SMTP-mail server; 

parsing an address header from said e-mail message with an e-mail delivery 
system; 

sending an e-mail source address obtained \n the step of parsing to a 
1 0 webserver; 

checking said e-mail source address against a list of source addresses maintained 
in a database associated with said webserver; 

instructing said e-mail delivery system from said websen/er to deliver or not- 
deliver said e-mail message to a user; 
15 displaying said e-mail message at said e-mail delivery system to said user if 

instructed to do so by said websen/er; and 

disposing of said e-mail message at said e-mail delivery system if instructed to 
do so by said webserver. 

20 2. The method of claim 1 , wherein: 

the step of sending an e-mail source address depends on transmitting an HTTP- 
message via the Internet to an active sen/er pages (ASP) equivalent application 
program operating on said webserver. 

25 3. The method of claim 1 , wherein: 

the step of instructing said e-mail delivery system depends on transmitting an 
HTTP-message via the Internet from an active server pages (ASP) equivalent 
application program operating on said webserver. 
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4. The method of claim 1 , further comprising the step of: 

registering an e-mail source in said database such that the step of checking will 
approve of said e-mail message if originated by that e-mail source. 



5 5. The method of claim 1 , further comprising the step of: 

preapproving a list of e-mail sources in said database such that the step of 
checking will allow delivery of said e-mail message if originated by any one of such e- 
mail sources. 

1 0 6. The method of claim 1 , further comprising the step of: 

allowing an e-mail source to list itself in said database such that the step of 
checking will allow delivery of said e-mail message if originated by such e-mail source. 

7. The method of claim 1 , further comprising the steps of: 
15 gathering identification information from an e-mail source not registered in said 

database; 

testing whether said identification information is acceptable according to a 
minimum standard; and 

if acceptable, allowing said e-mail source to be listed in said database such that 
20 the step of checking will allow delivery of said e-mail message if originated by such e- 
mail source. 



8. The method of claim 7, further comprising the steps of: 

issuing a first token to an e-mail source previously not registered in said 
25 database; and 

requiring said first token to be expired before the step of checking will allow 
delivery of said e-mail message when originated by such e-mail source. 



9. The method of claim 7, further comprising the steps of: 
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Issuing a second token to said e-mail source previously not registered in said 
database if said user validates them after having received and read one of their e-mail 
messages. 

5 10. An e-mail delivery system, comprising: 

a websen/er connected to a computer data network; 
an SMTP-mail sever for providing the delivery of e-mail messages to a user; 
a spam-elimination system connected to receive said e-mail messages from the 
SMTP-mail server; and 
10 a database of registered e-mail senders included in the websen/er; 

wherein, the spam-elimination system transmits any e-mail source address 
information included in any received e-mail messages to the webserver; 

wherein; the database is consulted for a registration listing matching said e-mail 
source address information; and 
15 wherein, the webserver provides for the instruction of the spam-elimination 

system to deliver or not deliver to a user a particular e-mail message. 

1 1 . The e-mail delivery system of claim 10, wherein the spam-elimination system further 
includes: 

20 a program subroutine for receiving an e-mail message from a sender via said 

SMTP-mall server; 

a program subroutine for parsing an address header from said e-mail message 
with an e-mail delivery system; 

a program subroutine for sending an e-mail source address obtained in the step 
25 of parsing to a webserver; 

a program subroutine for checking said e-mail source address against a list of 
source addresses maintained in a database associated with said webserver; 

a program subroutine for instructing said e-mail delivery system from said 
websen/er to deliver or not-deliver said e-mail message to a user; 
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a program subroutine for displaying said e-mail message at said e-mail delivery 
system to said user if instructed to do so by said webserver; and 

a program subroutine for disposing of said e-mail message at said e-mail 
delivery system if instructed to do so by said websen/er. 

5 

12. The system of claim 1 , wherein: 

the program subroutine for sending an e-mail source address depends on 
transmitting an HTTP-message via the Intemet to an active server pages (ASP) 
equivalent application program operating on said websen/er. 

10 

13. The system of claim 1 1 , wherein: 

the program subroutine for instructing said e-mail delivery system depends on 
transmitting an HTTP-message via the Intemet from an active server pages (ASP) 
equivalent application program operating on said websen/er. 

15 

14. The system of claim 1 1 , further comprising: 

a program subroutine for registering an e-mail source in said database such that 
the step of checking will approve of said e-mail message if originated by that e-mail 
source. 

20 

1 5. The system of claim 1 1 , further comprising: 

a program subroutine for preapproving a list of e-mail sources in said database 
such that the step of checking will allow delivery of said e-mail message if originated b y 
any one of such e-mail sources. 

25 

1 6. The system of claim 1 1 , further comprising: 

a program subroutine for allowing an e-mail source to list itself in said database 
suchthatthestepof checking will allow delivery of said e-mail message if originated by 
such e-mail source. 
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1 7. The system of claim 1 1 , further comprising: 

a program subroutine for gathering identification Information from an e-mail source 
not registered In said database; 

a program subroutine for testing whether said identification Information is 
acceptable according to a minimum standard; and 

a program subroutine for allowing said e-mail source, if acceptable, to be listed h 
said database such that the step of checking will allow delivery of said e-mail message if 
originated by such e-mail source. 

18. The system of claim 17, further comprising: 

a program subroutine for Issuing a first token to an e-mail source previously not 
registered in said database; and 

a program subroutine for requiring said first token to be expired before the 
checking will allow delivery of said e-mail message when originated by such e-mail 
source. 

1 9. The system of claim 1 7, further comprising: 

a program subroutine for issuing a second token to said e-mail source previously 
not registered in said database if said user validates them after having received and read 
one of their e-mail messages. 
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AMENUED CLAIMS 
[received by the International Bureau on 3 January 2002 (03.01.02); 
original claims 1-19 replaced by new claims 1-18 (8 pages)] 

REPLACEMENT CLAIMS 

1 . A method for stopping unwanted messages from being accepted in an 

e-mail delivery system, comprising: 

receiving an e-mail message from a sender via an SMTP-mail server; 

parsing an address header from said e-mail message with an e-mail 
delivery system; 

sending an e-mail source address obtained in the step of parsing to a 
webserver; 

checking said e-mail source address against a list of source addresses 
maintained in a database associated with said websen/er; 

instructing said e-mail delivery system from said webserver to deliver 
or not-dellver said e-mail message to a user; 

displaying said e-mail message at said e-mail delivery system to said 
user if instructed to do so by said websen/er; 

disposing of said e-mail message at said e-mail delivery system if 
Instructed to do so by said webserver; and 

allowing an e-mail source to list itself in said database such that the 
step of checking will allow delivery of said e-mail message if originated by 
such e-mail source. 
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2. The method of claim 1 , wherein: 

the step of sending an e-mail source address depends on transmitting 
an HTTP-message via the Internet to an active server pages (ASP) equivalent 
5 application program operating on said websen/er. 

3. The method of claim 1 , wherein: 

the step of instructing said e-mail delivery system depends on. 
transmitting an HTTP-message via the Internet from an active server pages 
10 (ASP) equivalent application program operating on said webserver. 



4. The method of claim 1 , further comprising the step of: 

registering an e-mail source in said database such that the step of 
checking will approve of said e-mail message if originated by that e-mail 
IS source. 

5. The method of claim 1 , further comprising the step of: 
preapproving a list of e-mail sources in said database such that the 

step of checl<ing will allow delivery of said e-mail message if originated by any 
20 one of such e-mail sources. 
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6. The method of claim 1 , further comprising the steps of: 

gathering identification information from an e-mail source not registered 
in said database; 

5 testing whether said identification Information Is acceptable according 

to a minimum standard; and 

if acceptable, allowing said e-mail source to be listed in said database 
such that the step of checking will allow delivery of said e-mail message If 
originated by such e-mail source. 

10 

7. The method of claim 6, further comprising the steps of: 

issuing a first token to an e-mail source previously not registered in 
said database; and 

requiring said first token to be expired before the step of checking will 
13 allow delivery of said e-mail message when originated by such e-mail source. 

8. The method of claim 6, further comprising the steps of: 

issuing a second token to said e-mail source previously not registered 
in said database if said user validates them after having received and read 
20 one of their e-mail messages. 
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9. An e-mail delivery system, comprising: 

a webserver connected to a computer data networl<; 

an SMTP-mail sever for providing the delivery of e-mail messages to a 

S user; 

a spam-elimination system connected to receive said e-mail messages 

from the SMTP-mail server, 

a database of registered e-mail senders included in the websen/er; and 
means for allowing an e-mail source to list itself in said database: 
10 wherein, the spam-elimination system transmits any e-mail source 

address information included in any received e-mail messages to the 

webserver; 

wherein; the database is consulted for a registration listing matching 
said e-mail source address information; and 
15 wherein, the webserver provides for the instruction of the spam- 

elimination system to deliver or not deliver to a user a particular e-mail 
message. 

10. The e-mail delivery system of claim 9, wherein the spam-elimination 
20 system further includes: 
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a program subroutine for receiving an e-mail message from a sender 
via said SMTP-mail server; 

a program subroutine for parsing an address header from said e-mail 
message with an e-mail delivery system; 

a program subroutine for sending an e-mail source address obtained in 
the step of parsing to a webserver; 

a program subroutine for checking said e-mail source address against 
a list of source addresses maintained in a database associated with said 
webserver; 

a program subroutine for instructing said e-mail delivery system from 
said webserver to deliver or not-deliver said e-mail message to a user; 

a program subroutine for displaying said e-mail message at said e-mail 
delivery system to said user if instructed to do so by said webserver; and 

a program subroutine for disposing of said e-mail message at said e- 
mail delivery system if instructed to do so by said webserver. 

1 1 . The e-mail delivery system of claim 1 0, wherein: 

the program subroutine for sending an e-mail source address depends 
on transmitting an HTTP-message via the Internet to an active server pages 
(ASP) equivalent application program operating on said webserver. 
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1 2. The e-mail delivery system of claim 1 0, wherein: 

the program subroutine for Instructing said e-mail delivery system 
depends on transmitting an HTTP-message via the Internet from an active 
5 server pages (ASP) equivalent application program operating on said 
webserver. 



1 3. The e-mail delivery system of claim 1 0, further comprising: 

a program subroutine for registering an e-mail source in said database 
10 such that the step of checking will approve of said e-mail message if 
originated by that e-mail source. 



14. The e-mail delivery system of clairri 1 0, further comprising: 

a program subroutine for preapproving a list of e-mail sources in said 

15 database such that the step of checking will allow delivery of said e-mail 

I 

message if originated by any one of such e-mail sources. 



15. The e-mail delivery system of claim 10, wherein said means for 
allowing an e-mail source to list itself in said database comprises a program 
20 subroutine for allowing an e-mail source to list itself in said database such that 
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the Step of checking will allow delivery of said e-mail message if originated by 
such e-mail source. 

1 6. The e-mail delivery system of claim 1 0, further comprising: 

a program subroutine for gathering identification information from an e- 
mail source not registered in said database; 

a program subroutine for testing whether said identification infomiation 
Is acceptable according to a minimum standard; and 

a program subroutine for allowing said e-mail source, If acceptable, to 
be listed in said database such that the step of checking will allow delivery of 
said e-mail message if originated by such e-mail source. 

1 7. The e-mail delivery system of claim 1 6, further comprising: 

a program subroutine for issuing a first token to an e-mail source 
previously not registered in said database; and 

a program subroutine for requiring said first token to be expired before 
the checking will allow delivery of said e-mail message when originated by 
such e-mail source. 



1 8. The e-mail delivery system of claim 1 6, further comprising: 
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a program subroutine for issuing a second token to said e-mail source 
previously not registered in said database if said user validates them after 
having received and read one of their e-mail messages. 
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